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, Abstract 

, Most current mobile agent systems are based on programming languages whose semantics 

are difBcult to prove correct as they lack an adequate underlying formal theory. In recent 
^ I years, the development of the theory of concurrent systems, namely of process calculi, has 

allowed for the first time the modeling of mobile agent systems. Languages directly based on 
process calculi are, however, very low-level and it is desirable to provide the programmer with 
higher level abstractions, while keeping the semantics of the base calculus. 

In this technical report we present the syntax and the semantics of a scripting language 
for programming mobile agents called Mob. Mob is service-oriented, meaning that agents 
, act both as servers and as clients of services and that this coupling is done dynamically at 

' run-time. The language is implemented on top of a process calculus which allows us to prove 

that the framework is sound by encoding its semantics into the underlying calculus. This 
provides a form of language security not available to other mobile agent languages developed 
using a more ah-doc approach. 
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■ 1 Introduction and Motivation 

The Service-oriented programming departs from the object-oriented paradigm by separating the 
data from the processing. Services are thus provided in a transparent way for clients, requiring 
only knowledge of the contract (service's interface). One of the main advantages of service-oriented 
programming is that they provide a framework on which to develop component-based systems. 
In such systems, inter-component communication is done through the contracts provided by each 
component. Most of the first service-oriented architectures were built resorting to DOOM |B] or 
to CORBA [9 . Such systems have recently received a lot of attention for distributed systems, 
namely with the .NET [12], Jini [THI and Openwings [TU] platforms. 

Another major technology for Web applications is that of Mobile Agents. Mobile agents are 
computations that have the ability to travel to multiple locations in a network, by saving their 
state and restoring it in a new host. This paradigm greatly enhances the productivity of each 
computing element in the network and creates a powerful computing environment, focusing on 
local interaction. In fact, mobile agents move towards the resources (e.g., data, servers) and 
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interact locally unlike the usual commimication paradigms (e.g., client-server), that require costly 
remote sessions to be maintained. 

Programming languages for mobile agents come in two flavors: those designed by hand and 
those based on formal systems. In the first set we have systems such as Aglets |7], Mole [1^] and 
Voyager [S] that mostly extend Java classes to define an agent's behavior. Providing a demonstra- 
bly sound semantics for these systems is rather diflicult given the gap between the implementation 
and an adequate formal model. Moreover, since it is not possible to access the state of the Java 
Virtual Machine (JVM) these systems have a hard time implementing autonomous mobile agents, 
which occasionally have to move between sites carrying their state and resuming their execution 
upon arrival to their destination. Another approach, still in the same set, is that of scripting 
languages such as D 'Agents jlj or Ara [H], that fully support agent migration but require specific 
virtual machine support. 

Languages in the second set are based on formal systems, mostly some form or extension 
of the TT-calculus [H]. This process calculus provides the theoretical framework upon which 
researchers can build solid specifications for programming languages. Languages can thus be 
proved correct hy design relative to some base calculus with a well established theory. Examples 
of such languages have been implemented in recent years, namely, JoCaml TyCO ^5], X- 
Klaim [l] , Nomadic Pict [21] , Acute [M] and Alice [15] . Although process calculi are ideal formal 
tools for the development of mobile agent frameworks, their constructs are very low-level and 
high-level idioms that provide more intuitive abstractions for programming are desirable. 

Here, we introduce a scripting language called Mob that aims to provide both language security 
and, a user friendly, seamless, programming style more characteristic of the first set of languages. 
The main novelties introduced in Mob are as follows: 

• Mob is service oriented, meaning that services, described as interfaces implemented by 
agents are the main abstractions of the language. Agents both provide and require services 
and they are bound to these dynamically as they move through the network; 

• the Mob language has been encoded onto a calculus that extends the LSD (Lexically Scoped, 
Distributed) 7r-calculus [13] with basic objects, expressions, and a strong migration primitive. 
The LSDTT-calculus is, in turn, a form of the 7r-calculus extended with support for distributed 
execution and mobility of resources and, with a well-studied semantics. Although this is not 
the focus of this paper, we hope to use the encoding to prove the soundness of the operational 
semantics of the language. This is particularly important as it provides a form of language 
security, in the sense of being correct hy design, not readily available in related languages; 

• the encoding onto the process calculus provides a full specification of the front-end of the 
compiler for Mob. The output of this front-end are the MoB source programs written into 
equivalent programs in the TyCO language [18', a concrete implementation of the LSDtt 
model. This allowed us to use both the compiler and the run-time system previously devel- 
oped for TyCO, respectively, as the back-end of the Mob compiler and as the basis for the 
run-time system for Mob; 

• the TyCO run-time is implemented on top of the JVM and thus takes advantage of its 
portability while keeping full control of the state of the virtual machine. This provides full 
support for agent migration while keeping portability across distinct hardware platforms; 

• a user friendly scripting programming style provides the high-level abstractions desirable for 
programming mobile agents as derived constructs from the core language, thus preserving 
the semantics; 

• extensions to the core virtual machine in the form of external calls can be used to interact 
with other services (not implemented in Mob, namely SMTP, FTP, HTTP or SQL for 
databases) , as well to execute as programs written in other programming languages, such as 
Java, Python or Perl. In this view. Mob can be used as a coordination language allowing 
high-level programming of mobile applications. 
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In the remainder of this paper we introduce the syntax and semantics of the Mob programming 
language. 

2 General Overview 

Before describing the language and its semantics, we give a short overview of the main features of 
Mob. We want to provide a simple to use programming language based on the high-level type- free 
programming feel of scripting languages. However, we also want to supply the means to develop 
clean, modular and structured code, and therefore we adhere to an object-oriented programming 
paradigm. 

Agents and services are the two main abstractions in the language. Conceptually, we view an 
agent as a special object, with a run-time associated, that can move from host to host in a network 
and that provides/requires services to/from that network. Agents are handled in Mob programs 
much like objects in object-oriented languages: the constructor agent is used to define an agent 
abstraction, and new is used to create a new instance of an agent. 

Data-types are defined with the usual class constructor. Objects are instances of these classes 
and, unlike agents, have no run-time associated. In Mob, objects are first class entities and are 
also created with the constructor new. 

Agents may implement services (declared through the provides keyword), and may, simulta- 
neously, be clients for the services provided by other agents, by requiring a service (the requires 
keyword). There is no distinction between clients and servers. 

Checking that an agent correctly uses or correctly implements the interface of a service is 
done at compile time by connecting to a network name resolver. The types inferred by the Mob 
compiler are matched with those assumed for the service in the resolver. If the agent implements a 
non-registered service, the interface provided becomes the de facto interface for that service. This 
level of type verification provides some form of program security, namely in method invocation 
across agents. 

To access a service, a programmer is required to get a binding for an agent that provides it. 
The binding is obtained dynamically using the bind primitive that asks the network resolver for 
an agent that provides the required service. When the binding is received, interaction through 
method invocation can happen. 

Agents may move through the network and this is controlled explicitly, at high-level by the 
programmer using a primitive go (similar to the one found in Telescript [20j). The movement of 
an agent involves moving an entire virtual machine and its state to the target host in the network. 
The execution resumes on arrival at the target host in a transparent way to users. 

Since agents supply services, they must be able to handle multiple incoming requests. To cope 
with such a demand we have designed agents to be multi-threaded. For example, each remote 
method invocation is handled by a dedicated thread. This design justified also the inclusion of 
explicit thread creation (fork) and synchronization (join, wait and notify). 

Objects in Mob can be accessed simultaneously by any number of threads, therefore a scheme 
to allow for exclusive access is required. We provide such a scheme with two instructions lock and 
unlock that allows a primitive form of mutual exclusion in data access. 

Interaction with external services is provided by Mob through the exec instruction. In general, 
exec is used to implement extensions to the core Mob language to support more functionality. 
These external services may be implemented in other languages, such as Java, C, TCL or Perl, 
or allow interaction with network services, such as WWW queries, FTP transactions, or e-mail 
communication . 

3 The Syntax 

We now present the syntax for the core language. The full form of the language is obtained by 
providing derived constructs for higher-level programming, while keeping the underlying semantics 
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5 P ; exit 
requires S 

agent X(x) provides S requires S M 
service S {m} 
class X(x) M 
I ; P 

e 

go (v) 
return (v) 
join (x) 
wait (x) 
notify (x) 

lock (x) I unlock (x) 

if (v) { P } else { P } 

while (v) { P } 

break 

exit 

X = V 

O.X ~ V 

new X (v) 
fork { P } 

bind (S v) | bind(S) 
host 

exec (v) 
o.m (v) 
e 

O.X 

{ini(xi) { Pi }...inn(Xn) { Pn }} 

V I e bop e | uop e 
o I c null 
X I self 

bool I int I string 

+ I - I * I / I % I 
&& I II I == I ! = 

< I > I <= I >= 
! I - 



A Mob program 
Require a sequence of services 
Agent definition 
Service definition 
Class definition 
Sequential composition 
Empty sequence 
Agent movement 
Method return 
Thread synchronization 
Suspend on a resource 
Wake threads suspended on a resource 
Lock/unlock resource 
Conditional execution 
Iterator 
Break 

Terminate agent execution 

Assignment 
Attribute assignment 
New agent or object 
New thread 
Service discovery 
Current host 
External service call 
Method invocation 
Expressions 
Attribute reading 
Methods 
Basic expressions 
Language values 
Target 
Constants 

Binary Operators 
Unary Operators 



Table 1: Syntax of the Mob programming language 



Program 


e 


Program 


D 


e 


Definition 


X,Y 


e 


Class 


S 


e 


Service 


m 


e 


Methodid 


P 


e 


InstructionSeq 


I 


e 


Instruction 


V 


e 


Assign Value 


M 


e 


Method 


e 


e 


Expression 


x,y 


e 


Var 


c 


e 


Constant 


V 


e 


LangValue 





e 


Target 


bop 


e 


BinOp 


uop 


e 


UnOp 



A Mob program 

Class, agent and service definitions, 
and service requirement 
Class or agent identifiers 
Service identifiers 
Method labels 

Sequence of program instructions 

Program instruction 

Assignable value 

Set of methods 

Basic expression 

Variable identifier 

Constant value 

Variable or constant 

Object or agent 

Binary operations 

Unary operations 



Table 2: Phrase categories 



agent provides requires class service main new 
go bind fork join wait notify lock unlock host exec 
if else while break return exit self null 

!{}()■; 

+ - * / % ==!=><>=<= && II 



Table 3: Reserved words 



of the core language. 

As defined in the grammar in table [H a MoB program is syntactically a sequence of definitions 
(D) followed by a sequence of instructions (P) terminated by exit. Tables [2] and [3] present, respec- 
tively, the phrase categories and the set of reserved words, that may not be used as identifiers, 
required by the syntax of a MoB program. 

We choose only to allow the assignment of language values to class and agent attributes. The 
assignment of an element in V to an attribute must use an intermediate auxiliary variable. This 
will be overcame in the full form of the language, with the inclusion of syntactic sugar. Here, 
it greatly simplifies the definition of the language's semantics, since we do not have to define 
duplicate rules for the assignment of the elements in V to either variables and attributes. 

Constant identifiers in Mob are divided in the following classes: booleans, elements of 
Bool = {true, false} ranged over by bool; integers, elements of Int ranged over by int and, 
strings, elements of String ranged over by string, defined by the regular expression: 
Hosts in Mob are represented with strings. 

Syntactic Restrictions 

The concrete syntax of Mob imposes some syntactic restrictions over the syntax of a program: 

• service definitions must precede service requirements that, in turn, must precede the defini- 
tions of classes and agents; 

• an agent must implement the main method; 
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• the return instruction can only appear within the body of a method; 

• the break instruction can only appear inside the body of a while instruction; 

• the go and exit instructions can only appear inside the body of a method in an agent 
definition; 

• the method identifiers in in {mi(xi) { Pi } . . .mn(xn) { Pn }}, and in service {m} are pairwise 
distinct; 

• the parameters x in an agent (agent X(x) provides S requires S M), a class (class X(x) M) or 
a method (m(x){P}) definitions are pairwise distinct; 

• a variable x is bound in P with an assignment (x = V;P), where V is a language con- 
struct that may appear on the left of an assignment; is bound in M in an agent definition 
(agent X(x) provides S requires S M) or class definition (class X(x) M) if it is one of the x; is 

bound in P in a method (m(x){P}) if it is one of the x; 

• an agent identifier X is bound in D, D', M and P with a statement 
D agent X(x) provides S requires S M 6' P; 

• a class identifier X is bound in D, 5', M and P with a statement D class X(x) M D' P; 

• a service identifier S is bound in D and P with a statement service S {m} D P; 

• the sets of free variables, free agents, free classes and free services are defined accordingly. 
Well formed Mob programs are closed for variables, agent identifiers, class identifiers and 
service identifiers. 

4 The Mob Abstract Machine 

We provide the semantics for a Mob network in the form of an abstract state transition machine. 
A Mob network is composed by a set of hosts, which are abstractions for network nodes. Hosts 
define the boundaries where computations take place in a Mob network. The computing units 
of the Mob language are agents. There may be several agents running concurrently in a given 
host at any given time. In our approach there is no distinction between clients and servers, any 
agent may behave as a client requesting a service while also providing services to others. This is 
achieved by implementing multi-threaded agents to handle multiple requests concurrently. The 
threads in an agent share the same heap space whilst having independent control data-structures. 

Before defining the structure of the network, of agents and of threads we first introduce the 
syntactic categories and auxiliary functions. 

4.1 Syntactic Categories and Data-Structures 

Besides the syntactic categories of the language, the abstract machine requires a new set of cate- 
gorie|3 defined in table ID 

The abstract machine has two layers: agents and threads. A network is described as a set 
of agents running concurrently plus a resolver for agents and services. Agents are described as 
collections of threads running concurrently and sharing the agent's resources, namely its code 
and address space. Agents are abstractions for autonomous programs running on network hosts, 
that interact with the network by spawning new agents or moving between hosts. Inter-agent 
interaction is performed by invoking methods. The abstract machine requires some syntactic 
categories and data-structures to be defined: 

^We denote the syntactic definition of methods in the language and their internal representation in the abstract 
machine with the same letter M. We choose to do so because both relate to the same information, although with 
different representations. 
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a,b 


e 


AgentKey 


Agent key 


C 


G 


Code 


Code for the class and agent definitions 


M 


G 


Method 


Methods of a definition 


H 


e 


Heap 


Address space for the agent 


r 


G 


HeapRef 


Heap reference 


t 


G 


ThreadRef 


Thread reference 


K 


e 


Closure 


Closure 


u 


G 


Value 


Constant value or a heap reference 


T 


G 


Pool(RunningThread) 


Pool of flows of execution 


B 


G 


Bindings 


Environment of a thread 


Q 


G 


CodeStack 


Stack of interrupted blocks of code 


W 


G 


SuspendedThread 


Threads suspended (waiting) on a heap 


A 


e 


Pool(Agent) 


Pool of agents 


a 


G 


Type 


Type of a service 


R 


G 


NamcService 


Name resolver 


ANS 


e 


AgentNameService 


Agent name resolver 


SNS 


G 


ServiceNameService 


Service name resolver 


N 


G 


Network 


Network 



Table 4: Syntactic categories of the Mob virtual machine 



• an Agent Key is an clement of the set AgentKey C String, ranged over by a, b, and represents 
a unique, network-wide, key for an agent; 

• a Host is an element of the set Host C String, ranged over by h, and represents a unique, 
network-wide, host identifier; 

• an Instruction is an element of the set Instruction, ranged over by I, and represents a Mob 
instruction. A sequence of instructions separated by ; is denoted by P G InstructionSeq; 

• Method represents a set of methods and is a map of the form Method = Methodid i— > 
Var* X InstructionSeq, ranged over by M, and represents the methods in a class or an agent; 

• the Code repository for an agent is a map defined as Code = Class ^ Bool x Var* x Method x 
Code X Service*, ranged over by C and represents the all the code required by a class or agent. 
The boolean value makes the distinction between the two (true = agent, false = class); 

• a Heap Reference is an element of the set HeapRef, ranged over by r, and is an abstraction 
for an address in the address space of an agent. Heap references in Mob are qualified with 
the key of their hosting agent (e.g., reference r in the heap of agent a should be interpreted 
as r@a) and thus are unique in the network. To ease the reading of the rules we omit the 
qualifier of a heap reference when it is accessed from within its hosting agent. The value 
null G HeapRef represents an undefined heap reference; 

• a Thread Reference is an clement of the ThreadRef C HeapRef, ranged over by t, and 
represents a reference to a thread. Note that this subset includes null; 

• a Constant is an element of the set Constant = Bool U Int U String, ranged over by c, and 
represents a primitive value of the language; 

• a Value is an element of the set Value = Constant U HeapRef, ranged over by u; 

• an Environment is a map defined as Bindings = Var ^ Value, ranged over by B, that 
represents a map from identifiers in the code to constants or references in the heap. We will 
represent the binding from an identifier x to a value u as x : u; 
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• a Closure is an element of the set Closure = Bool x Bindings x Class, ranged over by K, and 

represents the closure for an instance of a class or an agent located in an address space. The 
boolean value makes the distinction between instances of classes and agents; 

• a Heap is a map defined as Heap = HeapRef i— > ThreadRef x (Closure U Value), 
ranged over by H, and represents the address space of an agent. The contents associated with 
heap references may be accessed with mutual exclusion using locks. The thread reference 
in the image of a reference indicates which thread holds the lock to the contents. Unlocked 
references hold null has their thread reference; 

• a Code Stack is an element of the set CodeStack = StocA; (Bindings x InstructionSeq) . ranged 
over by Q, and represents the stack of blocks of code, used as a mechanism to implement 
while loops. The block of the top of the stack is the one currently being executed by the 
machine. As soon as it terminates, it is popped from the stack and the execution continues 
with the code of the block found at the top of the stack. We refer to elements of the stack 
as code-blocks; 

• a Pool of Running Threads is an element of the set Pool(RunningThread), ranged over by T, 
where RunningThread = ThreadRef x CodeStack x HeapRef represents a flow of execution. 
In the definition of a thread (t,Q,r), the thread reference t is a location in the heap to 
which the thread is bound. The reference r is a heap reference where the thread may place 

a result; 

• a Suspended Thread is a map defined as SuspendedThread = HeapRef h-» 2^"'^"'"8Thread^ 
ranged over by W, and represents threads suspended (waiting) on heap references; 

• a Pool of Agents is an element of the set Pool( Agent), ranged over by A, where Agent = 
AgentKey x Host x Code x Heap x Pool(RunningThread) x SuspendedThread represents a 
multi-threaded autonomous computation. We write an agent (a, h, C, H, T, W) as a(h, C, H, T, W) 
thus exposing the agent's key; 

• a Service Type is an element of the set Type, ranged over by a; 

• a Name Resolver, R, is composed by two maps, NameService = AgentNameServicex 
ServiceNameService. The first, defined as AgentNameService = HeapRef Host, ranged 
over by ANS, represents a network-wide name resolver for locating agents. The second, de- 
fined as ServiceNameService = Service Type x 2^*"^?^^^, ranged over by SNS, represents a 
network-wide name resolver for obtaining the type and implementations of a service; 

• a Network is an element of the set Network = Pool(Agent) x NameService, ranged over by 
N, and represents a Mob network computation. 

4.2 Auxiliary Definitions 

Function tryAccess checks if, in a heap H, the access to the value located at r is granted to a thread 
identified by t. 

tryAccess : Heap x HeapRef x ThreadRef Bool 



Function tryLock tries to grant the lock for a value located at r, in a heap H, to a thread 
identified by t. Function tryUnlock tries to release the lock for a value located at r in a heap H. 
The result of both functions is a heap modified (or not) by the operation, and a boolean value 
indicating if the operation was successful. Both these functions are atomic. 
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tryLock : Heap x HeapRef x ThreadRef 



tryLock(H, r, t) = 



Heap X Bool 

(H + {r : (t,K)},true), if tryAccess(H, r, t) = true 

and H(r) = (_, K) 
(H+ {r : (t,u)},true), if tryAccess(H, r, t) = true 

and H(r) = (_, u) 
(H, false), if tryAccess(H, r, t) = false 



tryUnlock : Heap x HeapRef x ThreadRef h- > Heap x Bool 

(H + {r : (null, K)}, true), if tryAccess(H, r, t) = true 

and H(r) = (_, K) 

tryUnlock(H,r,t) = (H + {r : (null, u)}, true), if tryAccess(H, r, t) = true 

and H(r) = (_,u) 
(H, false), if tryAccess(H, r, t) = false 

Remember that unlocked references have null as their locking reference. 
Function code returns the code for a method m from a given class or agent representation: 



code : (Var* x Method x Service*) x Mcthodid 

code((x, M,S),m) 



Var* X InstructionSeq 
M(m) 



Function codein returns the code closure for a set of methods. The result is a code repository, 
built from another received as argument, that is composed of the code for all the classes referenced 
in the set of methods. 



codein : Code x Method 
codeIn(C, M • (x, x = new X(v); P)) 

codeIn(C,M- (x, I;P)) 
codeIn{C,H- (x,e)) 
codeIn{<ll) 



Code 

{X : C(X)} + codeIn(C,M • (x,P)) 

codcIn(C, M ■ (x, P)) 

codein (C, M) 





if I X = new X(v); 



Function evalSeq returns the evaluation of a sequence of expressions, each element being eval- 
uated by the cval function. The evaluation requires the knowledge of the state of the heap H, the 
heap reference of the thread computing the expression r, and its environment B. The evaluation 
is fairly standard, however a particularity requires some closer attention. A variable may contain 
a heap reference whose value is another reference, which forces the rcsohition of the indirection. 

The value of a constant is given by the built-in val function, and the result of the relational 
and arithmetic built-in operations is given by the bop and uop built-in functions. 



evalSeq : (Heap x ThreadRef x Bindings x Expression*) 

evaJSeq(H, t, B, v v) 
evaJSeq(H, t,B, e) 



Value* 

evai(H, t,B,v) evaJSeq(H, t, B, v) 

£ 



(Heap X ThreadRef x Bindings x Expression) 


^ Value 




eval{K, t, B, c) 


= val(c) 




evaJ(H,t,B, null) 


= null 




evaJ(H, t,B, x) 


= val(c) 


if B(x) = c 


cvaJ(H, t, B, x) 


= null 


if B(x) = null 


evai(H, t, B, x) 


= t' 


if B(x) = t' 


eva](H, t, B, x) 


= r 


if B(x) = r and H(r) 


evai(H, t, B, x) 


= u 


if B(x) = r and H(r) 


eva7(H, t, B, e bop e') 


— bop(u, u') 


if evaJ(H, t,B, e) = u 






and evaJ(H, t, B, e') = 


evai(H, t, B, uop e) 


= uop(u) 


if evai(H,t,B, e) = u 
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Function copyScq^-^^ returns a copy of the closures for a sequence of values located in the heap 
of an agent a, plus all the code they require. The new references created to duplicate the given 
closure are located in the target agent b. The function takes as arguments the code repository C 
and heap H of the original agent a, and the sequence of values to be copied u. The copy of each 
value is computed by function copy^;^. 



copySeq^i, : Code x Heap x Value* 
copySeq^b(C,H,u u) 

copySeq^i,(C,H, e) 



Code X Heap x Value* 

(C' + C" , H' + H" , u'u ) where copy^ (C, H, u) = (C' , H' , u') 

and cop7Seq,,(C,H,ii) = (C",H",ii') 

(0,0, e) 



copjab ■ Code X Heap x Value 
copyab(C,H,r@a) 



Code x Heap x Value 

({X : C(X)} + C', H' + {r'@b : (null, (false, {x : u'}, X)}, r'@b)) 



if H(r@a) = (_, (false, {x : u}, X)) 
where copyScq^f^{C,E,ii) = (C',H',u') 
and r'Qb £ HeapRef fresh 
cop7ab(C,H,r@a) = (0J.r@a) if H(r@a) = (_, (true, {x : u}, X)) 

cop7ab(C, H, r@a) = (C', H' + {r'@b : u'}, r'@b) if H(r@a) = (_, u) 

where copy^^(C, H, u) = (C',H',u') 
and r'@b € HeapRef fresh 
copyab(C,H,r@a') = (0,0, r@a') if a' # a b 

copy,^{C,E,c) = (0,0, c) 

The run function places a set of pool of running threads in concurrent execution. 

run : 2f^"""'"sThread ^ Pool(RunningThread) 
run({(ti,Qi,ri),...,(tn,Qn,rn)}) = (ti, Qi, ri) | • • • | (tn, Qn, r^) 



4.3 The Initial and Final States 

Based on the above definitions, we may write the syntax for a network as follows: 



M 
A 



A,R 
A I A 

a(h,C,H,T,W) 
Oa 

T I T 

(t,Q,r) 

Ot 



Network 
Concurrent agents 
Running agent 
Terminated agent 
Concurrent threads 
Running thread 
Terminated thread 



For the sake of simplicity we assume that agents run in a static network with no failures. In 
other words, the set of available hosts. Host, is constant. Here we describe the abstract machine 
from the point of view of the execution of one agent. Thus, when we start running an agent, the 
network may already have a pool of agents A running concurrently and distributed among the 
network nodes in the set Host, together with the resolver R: 



A,R 
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We launch a program (D P) in the network by encapsulating its code (P) in an agent that is 
placed in a host specified by the user. The code repository for the program is collected at compile- 
time with function codeCoUect that we will defined ahead. Thus, when the agent is launched into 
the network it already contains all the code it requires. The initial state of the execution of a 
program with code 6 P is thus: 

a(h, codeCoIIect{t)), 0, launch{0, P, null), 0) | A, R 

where a is a fresh agent key, h is the local host and launch{B, P, r) is a macro that creates a new 
thread with an environment B (here 0), a code P (here P) and a return reference r (here null): 

a(h, C, H, lauDch{B, P, r) | T, W) | A, R = 
a(h,C,H + {t : (t,null)}, (t, (B,P),r) | T, W) | A, R t € ThreadRef fresh 

Note that no heap reference is associated with the agent a, since a program does not provide 
any methods, nor has attributes. Moreover, a is not registered in R, and thus is not accessible to 
the network. The registry is a precondition for an agent to migrate (further detail in rule [Go]), 
and thus. Mob programs cannot migrate, just agents. 

Agents are daemons by default and must be explicitly terminated by the exit instruction, 
which produces the terminated agent Oa. Thus, at the end of the program running in agent a, the 
configuration of the network will be of the form: 

Oa I a',r' 

Such an agent can thus be garbage collected and produce the state: 

A',R' 



4.4 Code Collection 

The compile-time code collection is defined by function codeCoUect : Definition* Code that 
returns a code repository with all the code required by a sequence of class and agent definitions. 
We present the function in a case by case analysis. 

A service specifies an interface implemented by some Mob agent. Service definitions are used 
to supply information to the type-system. Type-checking of a MoB program is performed at 
compile-time by matching the inferred types for services required or implemented by the agents 
with their definitions kept in the resolver. If the service is required by the program or if the program 
implements a known service in the network then its inferred type must match the interface for 
the service kept in the resolver. If the service is introduced for the first time by the program (an 
interface for it does not yet exist in the resolver) then the type inferred for the service will become 
the adopted interface for the service as registered in the resolver. So, when the agent is created, 
the SMS map is updated by adding the reference of the agent to every entry associated to a one 
of the implemented services. Anyway, these are handled at compile time and there is no need for 
them in the abstract machine. 

codeCollect{serv\ce S {m} D) = codeCollect{l)) 
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Simple classes define abstract data-types and we call their instances objects. The entry in the 
code repository associated with this definition contains a closure with slots for the code for all the 
classes and agents that are required by this class, its attributes, the code for its methods, and an 
empty sequence of implemented services, since an object does not provide any services. Remember 
that false indicates that the entry contains the code of a class. 

codeCollect{c\ass X(x) {mi(xi) { Pi } . . .mn(xn) { Pn }} D) = 
{X : (false, X, M', codeln(M'), e)} + codeCoUect{l)) 

where M' = {mi : (xi,Pi), . . . ,mn : (xn,Pn)}. 

Some classes are special in the fact that they represent full computations. We call their 

instances agents, and we use a different keyword to differentiate them. Otherwise, the definition 
of an agent is very much like that of a regular class, it contains the code for all the classes and 
agents required, the attributes, the code for the methods and indicates which services are provided 
by the agent. 

The requires keyword supplies information to the type-system, indicating which services are 
required by the agent and that their uses must be checked against the definitions in the SNS. 
The provides keyword does not only supply information to the type-system, but also states which 
service entries must be updated whenever an instance of the agent is created (rule [NewAgent]). 
To hold this information when necessary, we keep this sequence in the agent's code closure. 

codeCoJiect (agent X(x) provides § requires S' {mi(xi) { Pi } . . .mn(xn) { Pn }} 6) = 

{X : (true,x,M', codeJn(M'), §)} -I- codeCollect{l)) 

where M' = {mi : (xi,Pi), . . . ,mn : (x„,Pn)}. 

Note that agents may not always implement or require services and thus both S or S' may be 
empty sequences. 

The requires keyword can be also used by itself to indicate which are the services required by 
a program. Once again this only provides information to the compile time type checking, and thus 
there is no need to pass it to the run-time. Here we also present the base case for the recursion. 

codeCoJJect(requires § D) = codeCollect{D) 
codeCollect{e) = 



4.5 The Congruence Rules 

The computation in the abstract machine is driven by a set of reduction rules that operate over the 
thread or the agent at the most left in the respective pool. Thus, in order to be able to commute, 
associate and garbage collect threads and agents in their pools, we need a set of congruence rules. 
These will allow for the re- writing of both pools, into semantieally equivalent ones, where the 
configuration is accordingly to the reduction rules to be applied. The congruence rules for a pool 
of agents are: 

[AgentSwap] a I a' = A' I A [AgentGC] Oa | A = A 

[AgentAssoc] a I (a' I A") = (A I A') I A" 

The congruence rules for threads for threads are: 
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[ThreadSwap] t I t' = t' I T [ThreadGC] Ot I T s t 

[ThreadAssoc] t I (t' I t") = (T I t') I t" 



Rule [ThreadInAgent] allows the use of the congruence rules for threads in the layer of agent 
states: 



[THREADINAGENT] c, H, T | T", W)" ^ t(h, C, H, T' | T", W) 



4.6 The Reduction Rules 

Each Mob instruction requires at least one machine transition to be processed. The rules are 
written using the usual forms in the definition of operational semantics. The rules are of two 
forms: the first are denoted by 

A^A' 



and operate simply over a pool of threads. They are used whenever the operation to be performed 
does not modify the name resolver R. The second, denoted by 

A,R^ A',r' 

include the resolver and are used whenever the operation requests data from the resolver or modifies 

its contents in some way. To widen the scope of the first form of reductions to whole network we 
define rule rule [AgentRed] . This allows us to define rules focused on one agent alone, whenever 
the remainder of the network is not affected. 

a|a',r''-7a"|a',r 
Rule [Cong] allows reduction to occur under structural congruence: 
, k = k' a',r^a",r" a"=a"' 

A',R ^ A-,R" 

Next we provide the rules for the language constructs. 

Creation of Objects and Agents 

The instantiation of a regular class creates a new object. It reserves a block of heap space for a 
closure representing the object. The closure holds the values of the attributes, a special attribute 
self, that is a reference to the object itself, and keeps a link for the code of the class. 

evaJgeq(H, t, B, v) = u C(X) = (false, x, _, _, e) r' € HeapRef fresh 

[NewObject] a(h, C, H, (t, (B, x = new X(v) P) :: Q, r) ] T, W) 

a(h,C,H + {r' : (null, (false, {self : r', x : u}, X))}, (t, (B + {x : r'},P) :: Q,r) | T,W) 

Agents in Mob are similar to objects, but they have an execution unit associated to them. A 
new agent is placed in the network's pool of agents. In the beginning, its location is the same 
as the agent that created it. It is initiated with a heap containing its closure at r' (as in the 
[NewObject] rule). A new thread is created to execute the code of the agent's main method 
with the agent's environment B', given by the attributes and self, main is a required method that 
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defines the agent's initial behavior, an approach common to many programming languages. The 
parent agent keeps a binding to the reference r'@b of the created agent in x. 

The code repository for the new agent is composed of the code required by the values given as 
argument to the constructor (C'), plus all the code required by the agent definition ({X : C(X)}). 

[NewAgent] 

evalSeq{E, t, B, v) = u copySeq^.^{C, H, u) = (C', H', u') C(X) = (true, x, M, _, Si • • ■ Sk) 
code(C(X), main) = (e, P') B' = {self : r', x : u'} b e AgentKey and r'@b e HeapRef fresh 
SMS(Si) = (qi,Ki) ■■■ SNS(SO = (qi.,Ki.) Ki = {r@i | i £ {l,...,n}} ■■■ K,, = {r@i | i £ {l,...,m}} 
a(h, C, H, (t, (B, X = new X(v) P) :: Q, r) | T, W) | A, (ANS, SNS) ->■ 
a(h, C, H, (t, (B + {x : r'@b}, P) :: Q, r) | T, W) | 

b(h,C' + {X : C(X)},H' + {r' : (null, (true, B', X))}, Jauiicii(B', P', null), 0) | A, 
(ANS + {r'@b : h}, SNS + {Si : (ai, Ki + {r'@b}), . . . , Sk : (ak, Kk + {r'@b})} 

where k denotes the number of services implemented by the agent, and n and m denote, respectively, 

the number of implementations of services Si and Sj^ in the network. 

Note that both maps of the resolver are updated. The reference r'@b holding the agent's 
closure will be the key in the ANS map to locate the agent's current host (r'@b : h). Every entry 
of the SNS map corresponding to each of the agent's implemented services given as Ki, . . . ,K„, will 
be updated with r'@b, e. g., (Si : (ai,Ki + {r'@b})) for the implemented service Si. 



Multi-threaded Agents 

The fork instruction allows the explicit creation of a new thread by the programmer. The new 
thread inherits the environment of its creator and a handle is returned to the caller. This handle 
is associated to a newly created heap reference, that contains a null value and is used for inter- 
thread synchronization. The synchronization is achieved by granting the thread exclusive access 
to itself (see [Join] rules). 



t' £ ThroadRef fresh 
[Fork] a(h, C, H, (t, (B, x = fork {P'} ; P) :: Q, r) | T, W) ^ 

a(li,C,H + {t' : (t',null)},(t,(B + {x: t'},P) :: Q,r) | (t', (B,P'),null) | T,W) 



A thread can suspend waiting for the completion of another thread using the instruction join. 
The instruction uses the thread's handle returned by a previous fork statement. While it is 
running, a given thread has a reference in the heap associated to it (t'). In this scenario, any 
other thread that tries to perform the join operation will suspend on t'. 

fJoiNSuSPENDl evaJ(H,t,B,x)=t' H(t') = (t',null) t' ^ t 

^ ^ a(h,C,H,(t,(B,join(x) ;P) :: Q, r) | T,W) ^ a(li, C, H, T, W + {t' : (t,(B,P) Q,r)}) 

If the thread on which the synchronization is performed is no longer running, the reference 
associated to it is no longer locked. In this case, the operation succeeds and the execution continues. 

rj , evaJ(H, t, B, x) = t' (t = t' V H(t') = (null, null)) 

^ ^ a(h, C, H, (t, (B, Join(x) ; P) :: Q, r) | T, W) ^ a(h, C, H, (t, (B, P) :: Q, r) | T, W) 

If the code currently under execution terminates and the stack has no more elements, the 
thread has run out of code to execute and terminates, as in ride [End]. To give a more expressive 
writing of the reduction rules involving synchronization, we define the notify macro. The macro 
represents a thread that wakes up all the threads suspended on reference r. 



notify{r) = (null, e, r) 
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When a thread terminates its execution it uses this macro to wake up all the threads suspended 
on it. 



[End] a(h,C,H,(t,(B,e),null) | T,W) ^ a(h, C, H, notify(t) | T,W) 

The [NotifyThread] rule wakes up every thread suspended on the given reference. W(r) is 
the set of threads suspended on the reference r. 

[NotifyThread] a(h, C, H, notify(r) j T, W) ^ a(h, C, H, T | run(W(r)), W|d<,^(„)_t,}) 

Explicit synchronization is also supported in MOB by the wait and notify instnictionsm, that 
The first allows a thread to suspend on a reference, while the second is the language support to 
create to a notify thread, and thus wake every thread suspended on the given reference. 

[Wait! evaJ(H,t,B,x) = r' r V t 

^ ^ a(h, C, H, (t, (B, wait(x) ; P) :: Q, r) | T, W) ^ a(h, C, H, T, W + {r' : (t, (B, P) :: Q, r)}) 

evaJ(H, t,B,x) = r' 



[Notify] 



a(li, C, H, (t, (B, notify(x) ; P) :: Q, r) | T, W) a(li, C, H, notify{r) | (t, (B, P) :: Q, r) | T, W) 



Agent Movement and Discovery 

An agent may move to another host, changing the topology of the distributed computation, rule 
[Go]. The original host will proceed without the agent, and the later will resume its execution 
concurrently with the agents at the target host. In order to migrate an agent must be registered in 
the ANS map. The reference associated to the agent in ANS is discovered by following the binding 
for the self identifier. This can be done, since the go instruction can only appear inside the body 
of an agent definition's method. 

evaJ(H, t, B, v) = h' B(self) = r'@a r'@a e dom(ANS) h' € Host 



[Go] a(h,C,H,(t,(B,go(v) ;P) :: Q,r) ] T,W) | A, (ANS, SNS) ^ 

a(h', C, H, (t, (B, P) :: Q, r) | T, W) | A, (ANS + {r'@a : h'}, SNS) 

An agent may invoke a method in another agent only if it has a binding for the target agent's 
closure. Agent discovery in MOB is service-oriented, meaning that agents are discovered for the 
services they implement. The instruction bind consults the network resolver and retrieves a heap 
reference, r'@b, associated with an agent that implements a service S and is presently running in 
host h. Note that an agent cannot obtain a binding for itself. 

eva7(H,t,B, v) = h' SNS(S) = (q, {r@ai, . . . ,r@an}) 

3r'@b G {r@ai, . . . ,r@an| : ANS(r'@b) = h' A bia 
[Bind] l > > j \ / 



a(li, C, H, (t, (B, X = bind(S v) ; P) :: Q, r) | T, W) | A, (ANS, SNS) - 
a(h, C, H, (t, (B + {x : r'@b}, P) :: Q, r) | T, W) | A, (ANS, SNS) 



However, sometimes the host where the agent is running is irrelevant and is not taken is 
consideration when the reference is picked. In both these rules, the criteria used in choosing an 
agent is left to the implementation. 

SNS(S) = (g, {r@ai,...,r@an}) 3r'@b £ {r@ai, . . . , r@an} : b 7^ a 
[BindAny] a(h, C, H, (t, (B, X = bind(S) ; P) :: Q, r) | T, W) | A, (ANS, SNS) 

a(h, C, H, (t, (B + {x : r'@b}, P) :: q, r) j T, W) j A, (ANS, SNS) 



15 



Current Host 

The next rule returns the host where the agent is running. 
[Host] a(h, C, H, (t, (B, x = host() ; P) :: Q, r) | T, W) ^ a(h, C, H, (t, (B + {x : h}, P) :: Q, r) | T, W) 



Local Method Invocation 

Method invocation in objects can only be done within an agent. All objects are encapsulated 
within agents and thus, invoking a method in an object located in the address space of some other 
agent is not possible, unless the target agent's interface provides some means to access the object. 
Methods of the agent itself can of course be invoked both from within the agent, and from other 
remote agents. Rule [LocalInvoke] applies to the scenario of local invocations, both in objects 
and in agents. We guarantee this restriction by qualifying the reference with its location. 

The method invocation simulates a call stack by suspending the current thread, and by creating 
a new one, bound to the same heap reference (t), to execute the body of the method. The 
environment of the new thread is obtained from the target object's environment modified with the 
values assigned to the method's parameters. The result location is a fresh heap reference r", locked 
by the current thread and holding no value (r" : (t,null)). The current thread is then suspended 
on that roforonco r", waiting for the result. Its environment is modified by the binding of variable 
X to r", so that x holds the returned value once the current thread resumes its execution. By 
associating the new thread to the same heap reference as the one that invokes the method, the 
former gains access to all the resources locked by the later. 

[LocalInvoke] 

evaJSeq(H, t, B, v) = u B(o) = r'Qa tryAccess(H, r'@a, t) = true H(r'@a) = (_, (_, B', X)) 
code(C(X),m) = (x, P') r" € HeapRef fresh 
a(h, C, H, (t, (B, X = o.m(v) ; P) :: Q, r) | T, W) ^ 
a(h, C, H + {r" : (t, null)}, (t, (B' + {x : u}, P'), r"), W + {r" : (t, (B + {x : r"}, P) :: Q, r)}) 

Note that elements of the heap of the form r" : (t, null) (with r ^ ThreadRef and t ^ null) 
denote uniquely references waiting for results. This will be important when encoding MoB to the 

target process calculus. 

Rule [LocalInvokeLocked] states that if the object on which the method its to be invoked 
is locked by another thread, the current thread suspends on that object. 

[LocalInvokeLocked] 

B(o) = r'Qa tryAccess(H, r'@a, t) = false 
a(h, C, H, (t, (B, x = o.m(v) ; P) :: Q, r) | T, W) ^ a(h, C, H, T, W + {r' : (t, (B, x = o.m(v) ; P) :: Q, r)}) 

The return instruction terminates the execution of the current thread, places the result in the 
dedicated heap reference r, releasing its lock, and spawns a notify thread to wake up the thread 
waiting for the result. Thus, the image of r in the heap will now hold the returned value (null,u). 
The notify thread will cause any thread in W waiting on r to resume, simulating the call stack. 

[LocalReturn] 

evaJ(H, t, B, v) = u 

a(h, C, H, (t, (B, return(v) ; P) :: Q, r) j T, W) ^ a(li, C, H + {r : (null, u)}, notify(r) j T, W) 
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Remote Method Invocation in an Agent 

As in local method invocations, remote method invocations always launch a new thread (t') in 
the target agent to execute the corresponding cod^. The difference lies in the fact that the result 
slot of the thread, r"@a, is now a heap reference from the heap of the calling agent. Moreover, 
this thread in the case of remote invocations, does not execute the body of the method, but rather 
triggers a local invocation. This allows for the application of the [LocalInvoke] reduction rule 
to execute the method locally at the remote agent. 

The values assigned to the method's parameters are passed by value, except agents that are 
passed by reference). A copy of the arguments must be sent to the target agent and since this 
may include objects, a closure with the values and the classes they use must be constructed, using 
function copySeq. The local invocation performed at the target agent has arguments x, bound to 
the clones of the original values assigned to the arguments in the calling thread. 

[RemoteInvoke] 

evaiSeq(H, t, B, v) = li B(o) = r'@b H'(r'®b) = (_, (true, B', X)) 
cop,ySeq^j,(C, H, u) = (C", H", u) r"@a £ HeapRef fresh 
(a(h,C,H,(t,(B,x = o.m(v) ;P) :: Q,r) I T, W) | b(h', C, H', T', W')) | A, R ^ 
(a(h, C, H + {r" : (t, null)}, T, W + {r" : (t, (B + {x : r"}, P) :: Q, r)}) | 
b(h', C' + C", H' + H", launch{{se\{ : r', x : u'}, x = self.m(x); return x, r"®a) | T', W')) | A, R 

The return value from a remote method invocation must be placed in a reference in the heap 
of the calling agent. This value may include objects, and thus a closure with the value and the 
classes it uses must be constructed. Finally, a notify thread is placed in the pool of threads of 
the calling agent, that will trigger the [Notify] rule and awake the thread that performed the 
invocation. 

evaj(H,t,B,v) copy.JC, H, u) ^ (C",H",u') 

[RemoteReturn] (a(h, C, H, (t, (B, return(v) ; P) :: Q, r@b) | T, W) | b(h', C', H', T', W')) 1 A, R ^ 

(a(h,C,H,T,W) I b(h',C' + C",H' + H" + {r : (null, u')}, notify(r) | T',W')) | A,R 



Exclusive Access 

Values in the heap may be shared by several threads, therefore it is necessary to supply a mech- 
anism to ensure that a thread may gain exclusive access to a given value. The lock instruction 
gives exclusive access to a reference to the current thread. The operation is only allowed if no 
other thread has exclusive access over the reference. Note that although the inspected agent is the 
only one under the rule's scope, we qualify r' with its location. This is to point out that exclusive 
access operations can only be performed on references owned by the agent. 

evai(H, t,B,x) = r'@a tryLock(H, r'Qa, t) = (H', true) 
^ a(h,C,H,(t,(B,lock(x) ;P) :: Q, r) | T, W) ^ a(h, C, H', (t, (B, P) :: Q,r) | T, W) 

A thread that tries to obtain the lock of a locked reference suspends on the reference. 

[LockFailed] 

evai(H, t, B, x) = r'Qa tryLock(H, r'Qa, t) = (H, false) 
a(h, C, H, (t, (B, lock(x) ; P) :: Q, r) | T, W) ^ a(h, C, H, T, W + {r'@a : (t, (B, lock(x) ; P) :: Q, r)}) 

^From a practical point of view, the maximum number of threads allowed for one agent is implementation- 
dependent. Note that remote invocations are not anonymous, the invoking agent may be identified, since the 
agent's name qualifies the reference r"@a. This means that precautions to avoid abusive use from other agents may 
be achieved by adding a set of new preconditions to the rule. This, can be used for instance to avoid denial-of-service 
attacks. 

^Passing them by value would constitute a new form of migration. 
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Instruction unlock returns the public access to a given heap reference and notifies every thread 
suspended on it, so that they may resume their execution. 



[Unlock] 

cvaJ(H, t, B, x) = r'@a tryUnlock(H, r'@a, t) = (H', true) 
a(h, C, H, (t, (B, unlock(x) ; P) :: Q, r) | T, W) ^ a(h, C, H', notify(r'@a) | (t, (B, P) :: Q, r) | T, W) 

If a thread tries to free an object without having exclusive access to it, the operation is ignored. 

(;vaJ(H, t, B, x) = r'@a tryUnlock(H, r'@a, t) = (H, false) 



[UnlockIgnore] 



a(h, C, H, (t, (B, unlock(x) ; P) :: Q, r) | T, W) ^ a(h, C, H, (t, (B, P) :: Q, r) | T, W) 



Control Flow 

The machine defines a basic set of instructions dedicated to control the flow of execution (if, while, 
and breal<). The if instruction requires two reduction rules, selecting the branch according to the 
boolean value resulting of the evaluation of value v. Each of them executes the code of the selected 
branch followed by the instruction's continuation (P). 

„ „ , cvaj(H, t,B, v) = true 

[IFiRUEJ ^(h,C,H,(t,(B,if (v) {P'} else {P"} ;P) :: Q,r) | T,W) ^ a(h, C, H, (t, (B, P'; P) :: Q,r) | T,W) 



, , evaJ(H, r, B, v) = false 

^ "^""^ a(h, C, H, (t, (B, if (v) {P'} else {P"} ; P) Q, r) | T, W) ^ a(h, C, H, (t, (B, P"; P) Q, r) | T, W) 

The while instruction requires three rules. Rule [PushCont] simply pushes the continuation 
of the instruction to the stack. This is required to allow the use of the break instruction to branch 
out of the loop (see rule [Break]). 

[PushCont] 

a(h, C, H, (t, (B, while(v) {P'}; P) :: Q, r) | T, W) ^ a(h, C, H, (t, (B, P'; while(v) {P'}) (B, P) :: Q, r) | T, W) 

Rule [WhileTrue] executes the body of the while instruction composed with the instruction 
again, performing the loop. The process eventually stops when the value v evaluates to false. The 
execution then continues with the continuation popped from the stack. 

[WhileTrue] 

ovaJ(H, t, B, v) = true 

a(h,C,H,(t,(B,while(v) {P}) :: Q,r) | T, W) ^ a(h, C, H, (t, (B, P ;while(v) {P}) :: Q,r) | T, W) 
Rule [WhileFalse] emulates the end of the loop resorting to the break instruction. 

evaJ(H, t, B, v) = false 



[WhileFalse] 



a(h, C, H, (t, (B, while (v) {P}) :: Q, r) I T, W) ^ a(h, C, H, (t, (B, break) :: Q, r) | T, W) 



The break instruction branches out of the loop. It pops the current code-block from the stack 
and begins the execution of the continuation (the new top of the stack). The environment of the 
continuation is updated with the modifications performed during the execution of the loop. 

[Break] 

a(h,C,H, (t,(B, break ;P) :: (B',P') :: Q,r) | T, W) ^ a(h, C, H, (t, ((B' + B)|d„„(BO, P') :: Q,r) | T, W) 
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Execute External Services 

The exec instruction allows the interaction with external services. This interaction is defined by 
an interface of seven possible actions. 

• init: opens a session with a service, and returns a session identifier; 

• read: reads a given number of bytes from a session; 

• readLine: reads a line from a session; 

• write: writes the given data to a session; 

• action: posts an action to be performed by the service associated to the session; 

• isAlive: checks if the session is still active; 

• close: closes the session. 



The syntax of the exec instruction requires the existence of three arguments, of which the first 
is the string that determines which action is to be performed. The second argument is an integer 
value that, when the action is init, corresponds to the identifier of the service to be requested, 
and otherwise corresponds to the session identifier. The third argument is a string used to pass 
values to the action. The operation is performed by an internal built-in function exec that executes 
synchronously. Asynchronous calls can be performed by encapsulating the exec instruction in a 
new thread. 

[Exec] 

evaiSeq(H, t, B, vi V2 V3) = ui U2 113 exec(ui U2 113) = u 
a(h, C, H, (t, (B, X = exec(vi V2 V3) ; P) :: Q, r) | T, W) ^ a(h, C, H, (t, (B + {x : u}, P) :: Q, r) | T, W) 

The protocol to interact with an external service is initiated by the init action, that receives 
as argument an integer value that identifies the service, and returns the session identifier. Once 
the session is opened, a series of read, readLine, write, action, and isAlive actions may be 
performed. To terminate the session, the close action must be used. Below is an example of a 
session with a FTP server. We assume that the FTP service identifier is 4. 



X = exec("init" 4 "ftp.adomain"); 
x' = exec("action" x "GET afile"); 
x' = exec("read" x "4096"); 
y = x' ! = ""; 
while (y) { 

x' = exec("read" x "4096"); 

y = x' ! = ""; 

} 

x' = exec(" close" x "") 



The example begins by opening a FTP session with a server located at ftp.adomain. The 
correspondent session identifier is placed on x. Next, it posts the GET afile action to fetch file 
afile, and reads its contents in chunks of 4096 bytes. Once the file is read, it closes the session. 



Assignment of Expressions 

The result of the computation of an expression may be assigned to a variable. The assignment 
involves adding a new entry in the environment (B) of the thread. 

. , cvai(H, t, B, e) = u 

[ASSIGNMENT] ^(li, C, H, (t, (B, X = e ; P) :: Q, r) | T, W) ^ a(h, C, H, (t, (B + {x : u}, P) :: Q, r) | T, W) 
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Handling Attributes 



Assigning a value to an attribute of an object involves modifying the object's closure. Thus, an 
inspection to the status of both the object and the attribute is required. If the access to both is 
granted to the current thread, the binding of the given attribute in the object's closure is modified. 

[AttrAssignment] 

eval{H, t, B, v) = u B(self) = r' H(r') = (t', (bool, B', X)) tryAccess(H, r', t) = true 
{eval{E, t, B', x) = r" A tryAccess(H, r", t) = true) V evai(H, t, B', x) = c 
a(h, C, H, (t, (B, self.x = v ; P) :: Q, r) | T, W) ^ 
a(h, C, H + {r' : (t', (bool, B' + {x : u}, X))}, (t, (B, P) :: Q, r) | T, W) 

If not, the current thread may suspend on the reference holding the object, or on the one 
holding the actual attribute. Rule [AttrAssignmentLocked] covers the first case, where the 
thread cannot access the object. 

[AttrAssignmentLocked] 

B(self) = r' tryAccess(H, r', t) = false 

a(h, C, H, (t, (B, self.x = v ; P) :: Q, r) | T, W) ^ a(h, C, H, T, W + {r : (t, (B, self.x = v ; P) :: Q, r)}) 

Rule [AttrAssignmentLockedInAttr] covers the second case, where the thread has access 
to the object, but not to the attribute. 

[AttrAssignmentLockedInAttr] 

B(self) = r' H(r') = (t', (bool, B', X)) tryAccess(H, r', t) = true 
evai(H, t, B', x) = r" tryAccess(H, r", t) = false 
a(h, C, H, (t, (B, self.x = v ; P) :: Q, r) | T, W) ^ a(h, C, H, T, W + {r" : (t, (B, self.x = v ; P) :: Q, r)}) 

There is no access restriction on the reading of attributes. The rule simply retrieves the value 
of the attribute and binds the given variable to it. To ensure that correctness of the information 
to be read, the programmer must protect the access with a lock to the object. 

treadAttr] B(o)^r' H(rO^ (_,(_, B',X)) B'(y)=u 

J a(h, C, H, (t, (B, X = self.y ; P) :: Q, r) | T, W) ^ a(h, C, H, (t, (B + {x : u}, P) :: Q, r) | T, W) 



Terminate an Agent 

Finally, the [Exit] rule terminates the execution of an agent. This is required because agents 
are daemons and their execution must be explicitly terminated by the exit instruction. All the 
references to the agent in the network must be removed. 

[Exit] 

B(self)=r H(r) = (.,(., .,X)) C(X) = (.,.,.,., Si ■■■ Sn) 
SNS(Si) = (Qi,{r@ait,...,r@a, ...,rQaiJ) ... SNS(Sn) = (on, {r@ani , . . . , r@a, . . . , rQanJ) 
a(h, C, H, (t, (B, exit ; P) :: Q, r) | T, W) | A, (ANS, SNS) -> 
A, (ANS|dom{ANs)-{a}, SNS + {Si : (ai, {rOai^, . . . ,r@ai„}), . . . , Sn : (a^, {rOa^, . . . ,r@anj)}) 



5 The Type System 

In this section we present a type inference system for MoB that is very much inspired in the 
type-system developed by Vasco Vasconcelos for the TyCO calculus [17]. Types are ranged over 
by a, and are distinguished between types for primitive constants, ranged over by p, types for 
classes and agents, types for objects, instances of agents and services, and a denumerable set 
of variables for types, ranged over by t. A type for a class (or agent) is defined by a tuple of 
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two elements. The first holds the types for class (or agent) attributes, and the second, of the 

form /?, defines the type for the interface of the class (or agent). /? types arc records of the form 
{mi : (ai i-^- ai), mn : (an '-^ an)}, where mi denotes the identifier of a method; cij, the types 
of its parameters, and; a,, its return type. 



As in TyCO, types are interpreted as rational (regular infinite) trees. A type denoted by fxt.a 

with (a 7^ t) represents the rational solution for the equation a = t. An interpretation of recursive 
types as infinite trees induces an equivalence relation on types: a « a', if the tree solution for 
a = t and a' = t is the same. 

Expressions 

Typings for expressions are type assertions of the form e : a, for an expression e, and its type 
a. Expressions are formed by variables, constants, and operations over both of these. The type 
assignment is built from the types of constants and built-in operations and of types assigned 
to variables. The type of constants or a of built-in operation is given by the typeOf built-in 
function. The later are represented as an application of the types of the arguments into the type 
of the operation. For example typcOf{fa\se) = bool, and typcOf{>) = int int i-^ bool. For 
V = vi ... Vn, a sequence of pairwise distinct values, and a = ai ... a„, a sequence of types, we 
denote Vi : ai, Vn : an, a sequence of type assignments as: v : a. 



a ::= p 



j3 ::= {mi : {on ^ Qi), nin : (On i->- On)} 



p ::= int \ string \ bool \ thread 




Type of a primitive constant 
Type of a class or agent 
Type of an object, an agent instance, or a service 

Type variable 
Type relational tree 
Record type 
Primitive types 



[Const] The: typeOf{c) 



[Null] T h null : t 



t fresh A 



t p £ {int, bool, string} 



[Group] T \- e : a\- (e) a 



[Seqv] 



r h Vi : Qi . . . r h Vn : On 

r I- V : a 



[Var] r • X : a I- X : a 



[UnOp] 



typeOi(uop) = pi — > p2 r h e : pi 
r h uop e : p2 



[BinOp] 



typeOf(bop) = pip2 —^P3 r h ei : pi T h 02 : P2 
r h ei bop 62 : P3 
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Instructions 



Type assignments for agents and services are, correspondingly, type assertions of the form X : {a, 0) 
or S : Typings, denoted by F, is a map defined as: 



r : (Class U Service U Var) i-> Type 



that contains the type assigments for classes, agents, services, and variables. For 7 ranging over 
the elements of doni(r), wc have that r\7 denotes the typing obtained by F with its domain 
reduced from the elements in 7, and F(7) as the typing assigned to 7 if 7 G dom(F). We also 
denote the built-in identifier that holds the return type of a method mi. 

Type assignments for definitions, sequences of instructions and methods are thus denoted, 
respectively, by F h D, F h P and F h M. We begin by presenting the rules for service definitions 
and service requirement. Services are not removed from the set of typings until they are checked 
against the types defined for them in the network. Thus, when the local inference is done, the 
name resolver (R) is contacted to validate the local typings for the services. 

[Service] p , , ° J ^ ^ . „ (r(S) « {mi : (fii ai ),..., mn : (an On)}) 
i r service S |mi . . . mn| D P 



[Requires] ^ h D F h P ^ _ _ ^ 

r h requires S D P 

{Si :/3i,...,S„:^„}|-DP R = (ANS, SNS) 
[ServiceCheck] SNS(Si) = {(3[,.)--- SHS(Sn) = {(5'^, -) /3i w •■■/?„» 

I- D P 

Regarding classes and agents we define rules to type collections of methods, class and agent 
definitions. To allow mutual recursion between class and agent definitions we define two rules 
for both. One applied in the general case, and one other only applied when the definition is the 
last in the sequence. The later closes the system for definitions, removing them from the set of 
bindings by using a defs function that, given an set F, returns a sequence of all the elements from 
its domain that belong to Class. 

[MethodCollection] 

i l~ Xl : Oil i l~ Xretl : Qi Fh Pi • • • r h Xn : Ofn r I- Xretn '■ Oin i 1~ Pn 
r \ Xl Xretl ••• Xn Xretn ^ mi(xi){Pl} ••• mn(Xn){Pn} : {mi : fil l-» Ql , . . . , ffln : Qn H-S- Qn} 



,^ , r • self : (3 ■ self.xi : ai self.Xn -.a^hK: (3 PhD 67^6 Fl-P 

[Class] 



r h class x(x) M 5 P 



^ , r • self : P ■ self.xi : Qi self.Xn : an I- M : /3 F |- P 

[CLASSISLASTDEF] r\defe(r) h class X(x) M P 



r • self : f3 ■ self.xi : ai self.Xn : h K : (3 FhO D/e FhP 

[Agent] r h agent X(x) provides S requires s' M D P 

(r(X) « (a,/3), VS e S : r(S) « /3' ^ Vm e dom{/3') : m G dom(/3) A /3'(m) « /3(m)) 
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r ■ self : ■ self.xi : ai self.x„ : a„ h M : /3 T h P 

[AgentIsLastDef] r \defs(r) h agent X(x) provides S requires S' M P 

(VS € § : r(S) « /?' ^ Vm e dom{/3') : m € dom{/3) A /3'(m) fs /3(m)) 

We now define the rules to type sequences of Mob instructions (P): 



[Fork] 



r I- X : thread T h P' T h P 
r \ X I- X = fork{P'};P 



[Join] 



r I- X : thread T h P 
r h join (x);P 



[Wait] 



rh x:/3 ri-p 
r h wait (x);P 



[Notify] 



Th x-.p rhp 

r h notify (x);P 



[Lock] 



r h X : /3 r h p 

r h lock (x);P 



[Unlock] 



rh x:/? rhp 

r h unlock (x);P 



[Host] 



r I- X : string F h P 
r \ X h X = host();P 



[Go] 



r I- V : string T h P 
rh go (v);P 



[Expr] 



ri-x:a ri-e:a ThP 
r\x h x = e;P 



[IF] 



r h V : booJ r h p' r I- p" r h p 

r h if (v) {P'} else {P"};P 



[While] 



r h V : bool r\- p' r h p 

r h while (v) {P'};P 



[Break] 



rhP 



n- break; P 



r I- p 

[Exit] „ . — 
' r\- exit; P 



[Return] 



r I V : () r I Xr, 



1' , ' p 



r h return v; P 



,^ , r\-x: P ri-v: string T h P ,^ , , 
^^^■^1 r\x h x = bind(Sv);P ^^^'^ " 



[Bind Any] ^ / ^, ' "''^ J^fx (r(S) ^ /3) 
^ ^ r \ X I- X = bind(S);P ^ ^ ' ' ' 



[New] 



rhx:/? rhp 

r \ X h X = new X(v);P 



(r(X)«(a,/3) r(v)«a) 



[MethodInv] 



r hp 

r \ X h X = o.m(v);P 



(r(o) « {...,m : (a a), ...} r(v) « a r(x) q) 
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AttrRead — r o.y ^ a) AttrWrite -— — r o.y 

1 \ x h x = o.y;P 1 h o.y = x; P 



^ , r\- X : int r h vi : strine- r h V2 : int T h V3 : string- vi = " init" T h P 
[ExecInt] 



r \ X h X = exec(vi V2 V3);P 



r h X : string T h Vi : string T h V2 : int T h V3 : string 

[ExecString] (vi = "read" V Vi = "readLine") T h P 

r \ X h X = exec(vi V2 V3);P 



r h X : bool r h Vi : string T |- V2 : int F h V3 : string 
[ExecBoOl] (vi = "write" V Vi = "isAlive" V Vi = "action V Vi = "close") T h P 

r \ X h X = exec(vi V2 V3);P 



Next, we present two simple programming examples in Mob and execute one of them in the 
MobAM. 

6 Programming in Mob 

We exemplify the syntax with two small examples. We assume that two classes were previously 
defined. These are Array and Map, and implement the usual operations with arrays and maps. 
FILEEXEC and 10 are two integer constants that we also assume that were previously defined. 
Besides the Array and Map classes, these examples resort only to the base core Mob constructs, 
hence their verbosity. 

The first example is that of a server and a client for a clock synchronising service (Time). The 
server in listing [T] provides a service that features a single method getTimeO (lines 5 to 10). Note 
that the main method in line 4 may be empty since Mob agents run as daemons and some external 
action is required to terminate their execution. The program, not the launched agent, terminates 
with the exit instruction at line 13. 

Listing 1: A time server agent 

service Time { getTime } 
agent TimeServerO provides Time { 
main { } 

getTime () { 

d = execC"init", FILEEXEC, " ge t T ime Appl i cat i on " ) ; // Open the session 

X = exec C " readLine " , d, ""); // Read the output of the application 

status = exec(" close", d, ""); // Close the session 

return (x) ; 

} 

} 

X = new TimeServerO; // Create agent 

exit; // Terminate program 

The client (listing [2]) requires the Time service in line 1 and, when run, takes an array of hosts 
and performs a cycle (lines 7 to 16) in which it moves to each of them in line 9, setting their 
clock according with central time from the TimeServer (lines 10 to 13). Lines 19 to 22 construct 
the array to be passed as argument to the instance of the agent created in line 23. The program 
terminates its execution in line 24. 
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Listing 2: A time client agent 

1 agent TimeClient ChostList ) requires Time { 



3 




ma i n ( ) { 




4 













iter = hostList . iterator C) ; 


/ / Build condition for white 


D 




hasNext = iter . hasNext C) ; 








cond — hasNext — — true j 




g 




while CcondJ "C 


/ / lOr 3ll nosts mi^rste snd execute set 1 ime/\pplic3tion 


9 




liostName — iter uextC^" 


/ / Next host 


10 




go ChostName} ; 


^ ^ Go to the next host 


1 1 




time — timeServer. getTime () i 


Get time from server 


12 




comm.aiid ~ "setTimeApplication " time; 


Build commsnd to execute 


13 






^ ^ ^pen session to execute the 3 pplic3tion 


14 




Status = execC" close", d, ""); 


/ / Close session 


15 




hasKext = iter.hasNextC); 


/ / Build condition for while 


16 




cond = hasNext == true ; 




17 




} 




18 




} 




19 


} 






20 


ho 


sts = new ArrayCnull, 0); 


/ / Construct 3rr3y 


21 


X 


= hosts .put ("hostl . netl") ; 




22 


X 


= hosts .put ("host2 . net2") ; 




23 


X 


= hosts .put ("hosts . net3") ; 




24 


X 


= new TimeClient (hosts ) ; 


// Creste 3gent 


25 


exit; 


// Terminste progrsm 



Another, slightly more complex application is a minimal Messenger service implemented in 
listing[3] The Messenger service, defined in line 1, provides three methods: a client may log in the 
system (login), log out from the system (logDut) or ask who is currently on-line (getLogged). 
Their implementation is done respectively in lines, 4 to 7, 8 to 11, and 12 to 14. The instance of 
the agent is created in line 17, with the map created in the line before. The programs terminates 
its execution in line 18. 

Listing 3: A messenger server agent 



1 service Messenger {login logQut getLogged } 

3 agent MessengerServer ( logged) provides Messenger { 

5 login (nickname , client) -[ // Log in the system 

6 X = logged . add (nickname , client); 

7 return (null); 

8 } 

10 logDut ( ni ckname ) { // Log out from the system 

11 X = logged . remove (nickname ) ; 

12 return (null); 

13 } 

15 getLoggedO -( // Ask who is on-line 

16 return (logged); 

17 } 

18 } 

19 logged = new Map (null , 0); // Create initial empty map 

20 X = new MessengerServer(logged) ; // Create agent 

21 exit ; // Terminate program 



The particular messenger client in this example (listing |4]) first binds to the service and logs in 
the system (lines 7 to 9). Then, it initiates an input/output service (lines 10 and 11) and starts a 
loop (lines 12 to 35) in which the people currently on-line are listed (lines 13 to 23) and waits for 
the nickname in the input at line 24. The input triggers the creation of a new session between the 
client and the selected peer. The session is handled by a dedicated thread, which allows for several 
simultaneous conversations (lines 25 to 33). During the session, any input from the keyboard of 
the client is sent to the receptor (lines 29 to 33), until the "quit" keyword is typed to end the 
session. 

A client provides the MessengerPeer service, defined in line 1, to provide the method that 
receives and prints remote messages (lines 38 to 41). A client is terminated by some event that 
invokes the close method (lines 43 to 47) that logs out from the system and halts the agent's 
execution. 
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Listing 4: A messenger client agent 



1 


service MessengerPeer -[ printMessage 


> 




3 


agent MessengerCl lent (nickname , server , peersMap , io) 


4 


provides MessengerPeer reciuires 


M e s s e n 


ger { 




■ 

m 3 1 n C } 1. 






7 


aux = bind (Messenger) J 




/ / Discover service 


g 


self. server = x; 




/ f Assign it to tiie server attribute 


9 


X ~ server . logIn(nicknanie , self) j 




^ ^ Log in the server 


10 


aux = exec ( " init " , 10 , " " ) ; 




^ / Open standard input/ output session 


11 


self.io — aiixj 




/ / Assign it to tiie lo attribute 


12 


while (true) ■{ 






13 


aux = server . ge"tLogged.() j 




/ f (Jbtain peers logged in the server 


14 


self ■ peersMap ~~ aux^ 




/ / Assign them to the peers!\^3 p a ttri bute 


15 


iter — peersMap . iterator () ^ 




/ / Obtain an iterator over the map of peers 


16 


hasNext = iter.hasNext()j 




/ f Build condition for while 


17 


cond. = hasNext == true j 






18 


while ( cond) -[ 






19 


p = iter . next ( ) ; 




/ / i\lext peer 


20 


X = exec(" write", io, p); 




/ f Write the names of the people logged on the server 


21 


hasNext = iter . hasNext () ; 




/ f Build condition for while 


22 


cond = hasNext == true; 






23 


> 






24 


chosen = exec("readLine", io, " 


") ; 


/ / Read the name of the peer selected for conversation 


25 


fork { 






26 


peer = peersMap. get(chosen); 




// Read first message to be sent 


27 


line = exec("readLine", io, " 


") ; 




28 


cond = line != "quit"; 






29 


while (cond) { 




/ / While in conversation send message and read next 


30 


dummy = peer . printMessage(line) ; 




31 


line = exec("readLine", io. 


" " ) ; 




32 


cond = line != "quit"; 






33 


} 






34 


> 






35 


} 






36 


} 






38 


printMessage(line) { 






39 


X = exec(" write", io, line); 




/ / Print message in the screen 


40 


return (null); 






41 


> 






43 


closeO -[ 






44 


X = server. logOut(nickn am e); 




/ / Send logout message to the server 


45 


status = execC" close", io, ""); 




// Close input/output session 


46 


exit; 




/ / Terminate agent 


47 


} 






48 


} 






49 


X = new Me s sengerC 1 i ent ( " ni ck " , null , 


null , 


null); // Create agent 


50 


exit ; 




/ / Terminate program 



7 Executing an Example 

We are now going to exemplify how a Mob script its executed by the MobAM. Our case studies 
will be the TimeServer and TimeClient examples. We will only provide a partial execution of both. 
We will focus on the creation of the agents and on their interaction, skipping some of the steps that 
are not directly related with these operations, and terminating our execution once the interaction 
is over. 

Scripts are executed in the MobAM by encapsulating them in agents that execute their code. 
We assume that the Mob network target of our example is denoted by: A, R. In the sequel, we 
underline the components that have been altered by the application of a rule of the MobAM. 

We begin by launching the TimeServer script from listing [TJ We create a fresh key (a) for the 
agent running the script. The configuration of the network once we launch the agent is: 

a(h, C, Jaunch(0, X = new TimeServer 0; exit, null), 0) | A, R ^ 

where C = {TimeServer : (true, e, {main : (e, e), getTime : (e, P)}, 0, Time)} is the result of the 
application of function codeCoUcct to the program. Unfolding the launch macro we have: 
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a(h, C, {t : (t,null)}, (t, (0, x = new TimeServer(); exit), null), 0) | A,R ^ 

Applying rule [NewAgent] we create the new TimeServer agent. Since rule [New Agent] is 
somewhat extensive we present it again. 

[NewAgent] 

evalSeq{E, t, B, v) = u copySeq^-^,{C, H, u) = (C', H', ii') C(X) = (true, x, M, _, Si ... S^) 
code(C(X), main) = (e, P') B' = {self : r', x : u'} b G AgentKey and r'Qb G HeapRef fresh 
SMS(Si) = (qi,Ki) ■■■ SNS(Si,) = (qi.,Ki,) Ki = {rQj | i g {l,...,n}} ■■■ Ki. = {r@i | i g {!,..., m}} 
a(h, C, H, (t, (B, X = new X(v) P) :: Q, r) | T, W) | A, (ANS, SNS) 
a(h, C, H, (t, (B + {x ; r'@b}, P) :: Q, r) | T, W) | 

b(h, C' + {X : C(X)}, H' + {r' : (null, (true, B', X))}, iauncL(B', P', null), 0) | A, 
(ANS + {r'@b : h}, SNS + {Si : (oi, Ki + {r'@b}), . . . , Sk : (ok, Kj, + {r'@b})} 

For the sake of readability we assume that there is no implementation of the Time service in 
this network, and thus that SNS(Tiine) = (ai,0). We know that the code for main is e, and that 
TimeServer has no attributes. Thus, we do not require the cloning of the attributes. The code 
for the new agent b is simply the code for the class itself, meaning C. Thus, by applying rule 
[NewAgent] we obtain: 

a(h, C, {t : (t,null)}, (t, ({x : r@b}, exit), null), 0) 
b(h, C, {r : (null, (true, {self : r}, TimeServer))}, 7auncL({self : r}, e, null), 0) | A, 

(ANS + {r@b : h}, SNS + {Time : (en, {r@b})}) 

We may now use the [Exit] rule to terminate the execution of the script (in agent a) , and rule 
[AgentGC] to garbage collect the resulting Oa agent. 

Oa 1 b(h, C, {r : (null, (true, {self : r}, TimeServer))}, Jauncii({self : r}, e, null), 0) ] A, 

(ANS + {r@b : h}, SNS + {Time : (oi, {r@b})}) = 
b(h, C, {r : (null, (true, {self : r}, TimeServer))}, Jaunch({self : r}, e, null), 0) | A 

(ANS + {r@b : h}, SNS + {Time : (oi, {r@b})}) =^ 

From now on we will denote (ANS + {r@b : h}, SNS + {Time : (ai, {r@b})}) as (ANS', SNS') = R'. 
We proceed unfolding the launch macro. 

b(h, C, {r : (null, (true, {self : r}, TimeServer)), t' : (t', null)}, (t', ({self : r}, e), null), 0) | A,R^ 
Since the code for main is empty, we may apply rule [End] to terminate the thread. 

b(h, C, {r : (null, (true, {self : r}, TimeServer)), t' : (t', null)}, notify{t'), 0) | A, R' 

To notify the threads suspended on t' we apply rule [Notify]. Note that there are no sus- 
pended threads, and thus the rule does not wake any thread. 

b(h, C, {r : (null, (true, {self : r}, TimeServer)), t' : (t', null)}. Or, 0) | A,R' 

We denote this network configuration as A',R', and launch the TimeClient from listing [2] script 
onto it. Note that, in order to avoid using to many identifiers, we may repeat some of the ones 
used for references, since they are lexically bound to the agent that hosts them. 

Let a' be the key for the agent executing the client script at host h', and P' be the code for the 
main method of the TimeClient agent. The initial state of the network with the spawning of the 
new agent is: 
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a'(h',C',0, Jauiicii(0, hosts = new Array(null,0); exit, null), 0) | a', r' = 



where C' = Co + {TimeClient : (true, hostList, {main : (e, P')}, Co, e)} is the code repository 
for agent a' (result of the codeCoUect function) that holds in Cq the code for the Array class. 
Unfolding the launch macro we have: 

a'(h', C', {t : (t, null)}, (t, (0, hosts = new Array(null, 0); exit), null), 0) | a', r' 

We now jump to line 23 and skip the creation of the hosts array. Assume that at the time of 
the creation of the agent, variable hosts is bound to a reference r, that holds the entire array. We 
denote the heap of a' at this point as H, and the set of bindings of the thread as B that contains 
{hosts : r}. In line 23 we find the creation of the agent: 

a'(h',c',H, (t, (B,x = new TimeClient(hosts); exit), null), 0) | a', r' 

We now apply rule [New Agent] to create the agent. For that we introduce a new agent key, 
b'. The values given to the attributes of the class must be cloned. We thus perform the cloning 
of the reference bound to hosts and collect the code required by the methods of the Array class 
(of which hosts is an instance). 

evaJSeq(H,t,B, hosts) = r 

cop7Scq,,,,(c',H,r) = (Co,H',r') 
codeIn(c',main(){p'}) = 

H' and Cq arc respectively the heap and code closure for r'. Thus, the heap of the new agent will 
be H' + {r" : (null, (true, {hostList : r'}, TimeClient))}, where r" is the reference that holds the 
agent's closure. Since hosts holds an array, the only code required by the reference associated to 
it in the new agent is the Array class, kept in the Co code repository. Thus, the code repository 
for the new agent will be Co + {TimeClient : (true, hostList, {main : (e,P')}, Co, e)} = C', which 
contains the code for Array and TimeClient. Note that the methods of class TimeClient do not 
require any extra code. The resulting state is: 

a'(h',C',H, (t,( B + {x : r"@b'} , exit ).null), 0) 
b'(h', C', H' + {r" : (null, (true, {hostList : r'}, TimeClient))}, launch{{se\f : r"}, P', null), 0) | 

a', ( ANS' + {r"@b' : h'} , SNS') 

We then terminate the execution the client script (agent a') and garbage collect it to obtain: 

b'(h', C', h' + {r" : (null, (true, {hostList : r'}, TimeClient))}, Jauncii({self : r"}, ?', null), 0) | 

A',(ANS' + {r"@b' :h'},SNS') = 

Unfolding once again the launch macro we obtain the state of the client prior to its interaction 
with the Time service provider: 

b'(h', C', H' + {r" : (null, (true, {hostList : r'}, TimeClient)), t' : (t', null)}, 

(t', ({self :r"},P'), null) , 0) | 
A', (ANS' + {r"@b' : h'},SNS') 
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Remember that A' = b(h,C',{r' : (null, (true, {self : r'}, 0, TimeServer)), t' : (t',null)}, Or, 0) | A. 

To perform the interaction between both agents we need to expose both their states from the net- 
work. To present a less extensive state we denote the heap of each agent as: 

h" = {r : (null, (true, 0, TimeServer)), t' : (t',null)} 
h'" = h' + {r" : (null, (true, {hostList : r'}, TimeClient)), t' : (t', null)} 
Thus, by using the congruence rules we can obtain the following configuration of the network 
with both agents exposed and associated: 

Client Server 



(b'(h',C',H"',(t',({self :r"},timeServer = bind(Time); ...), null), 0) | b(h, C, H", Oi, 0)) | A, 

" ./ ' 

p' 

(ANS' + {r"@b' :h'},SNS') ^ 

We are now going to execute some of the code in P', the code for the main method of the client. 

We begin in line 3, where we apply rule [BindAny]. We know that {r@b : h'} is present in the 
resolver, thus r@b is the result of the binding operation. 

(b'(h'.C'.H"'.(t'.({self : r'. timeServer : r@b }, i = hostList. iteratorQ ; ...), null), 0) | 

b(li, C, h", Ot, 0)) I A, (ANS' + {r"@b' : h'}, SNS') s^* 

Next we proceed with the execution of agent b'. In order to apply rules over this agent, we 
have to disassociate it from agent b. For that we use rule [Agent- Assoc]. 

b'(h', C', H'", (t', ({self : r", timeServer : r@b}, i = hostList. iterator(); ...), null), 0) | 

b(h, C, H", Ot, 0) I A, (ANS' + {r"@b' : h'}, SNS') 

Now we have a state from which we may execute agent b'. In its code we skip the instructions 
until line 9, where we find a go. Consider that the current state is: 

b'(h',c',H'",(t',(B',go(hostHame); ...), null), 0) | b(h, C, h", Ot, 0) | A, (AHS' + {r"@b' :h'},SMS') -» 

where we denote the updated bindings as B', assuming that B'(hostNaine) = h". We now apply 
rule [Go] to migrate the agent to h": 

b'(h^,C',H'", (t', (B', time = timeServer.getTimeQ ;...), null), 0) | b(h, C, h", Ot, 0) | A, 

( AMS' + {r"@b' :h"} ,SHS') = 

Next, we have a method invocation on the timeServer agent. Since B' (timeServer) = r@b, 

and the agent running the thread is b', the invocation is remote. We have thus to apply rule 
[RemoteInvoke] . Neither the heap, nor the code repository of the target agent are modified, 
since the method as no parameters. Before applying it, we remember the rule for remote invocation. 

[RemoteInvoke] 

evaJSeq(H, t, B, v) = ii B(o) = r'Qb H'(r'@b) = (_, (true, B', X)) 

copySeq^t^jC, H, u) = (C', H", u ) r"@a £ HeapRef fresh 

(a(h,C,H,(t,(B,x = o.m(v) ;P) :: Q,r) I T, W) | b(h', C, H', T', W')) | A, R 
(a(h, C, H + {r" : (t, null)}, T, W + {r" : (t, (B + {x : r"}, P) :: Q, r)}) | 
b(h', C + C', H' + H", Jaunch({self : r', x : u'}, x = self.m(x); return(x), r"@a) 1 T', W')) | A, R 

Before applying the rule we have to associate the agents that will take part on the communi- 
cation. Thus, applying rule [AgentAssoc] we have: 
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(b'(h^,C',H"', (t', (B', time = timeServer.getTimeQ ;...), null), 0) | b(h, C, h", Ot, 0)) | A, 

( ANS' + {r"@b' : h"} , SNS') ^ 

We may now apply rule [RemoteInvoke] to create the new thread in the target agent, and 
suspend the calling thread, waiting for the result. 

(b'(h",C', H"' + {r" : (t',null)} ,OT, {r'" : {(t', (b' + {time : r"}, command = ...;), null)} }) | 
b(h, C, h", JauncJi({self : r}, x = self.getTimeQ; return(x), r"'@b') | Ot,0)) | A, 

(ANS' + {r"@b' :h"},SNS') = = 

Now we proceed the execution in agent b to execute the method. To have a state on which we 
can apply rules over b, we have to disassociate the agents and commute their position. 

b(li, C, h", Jamicii({self : r}, x = self.getTimeQ; return(x), r "@b') | Ot, 0) | 
b'(h", C', E'" + {r'" : (t',nmi)}. Ox, {r'" : {(t', (b' + {time : r'"}, command = ),nmi)}}) | A, 

(ANS' + {r"@b' :li"},SNS') = 

From now on we denote (ANS' + {r"@b' : h"},SNS') as R". Unfolding launch we create a new 
thread associated to a new thread reference (t"). 

b(h, C, h" + {t" : (t", null)} , (t", ({self : r}, x = self.getTimeQ; return (x) ), r"@b') | Ot,0) | 
b'(li",C',H"' + {r"' : (t',null)},OT,{r"' : {(t', (b' + {time : r'"}, command = ...;), null)}}) | A,r:: ^ 

We now apply rule [LocalInvoke] to perform the local invocation in b. We know that: 

H"(r) = (null, (true, 0, TimeServer)) 
C(TimeServer) = (true, e, {main : (e, e), getTime : (e, P)}, 0, Time) 

Thus, P is the code to execute. We create a new reference r' to hold the result of the method, 
suspend the current thread on it, and create a new thread, associated to the same reference as the 
current (t"), to execute the method. 

b(h,C,H" + {t" : (t",null), r' : (t", null) }, (t", (0, P), r'), {r' : {(t", ({x : r'}, return(x)), r'"@b')}} ) | 

b'(h",C',H"' + {r"' : (t',null)},OT,{r"' : {(t', (b' + {time : r'"}, command = ...;), null)}}) | A,r" ^ 

The body of the method (P) executes until it reaches a return instruction, that returns the 
value for the time (c). Consider that B" are the updated bindings of the thread executing getTime, 
and that B"(x) = c. 

b(h,C,H" + {t" : (t",null),r' : (t",null)}, 
(t",(B::, ret»m(x) ),r'),{r' : {(t", ({x : r'}, return(x)), r"'@b')}}, 0) | 
b'(h",c',H"' + {r'" : (t',null)},OT, {r'" : {(t', (B + {time : r'"}, command = ...; ),null)}}) | A,r" ^ 

We will now apply rule [Return] . The value is placed on the correspondent reference. 

b(h,C,H" + {t" : (t",null), r : (null, c) }, notify(r ), {r : {(t", ({x : r'}, return(x)), r"'@b')}}) | 
b'(h",C',H"' + {r'" : (t',null)},OT,{r"' : {(t', (B + {time : r'"}, command = ...;), null)}}) | A,R" ^ 
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Applying rule [Notify]. Note that, from the definition of run in section [H we have that: 
rufl({(t", ({x : r'}, retum(x)), r"'@b')}) = (t", ({x : r'}, return(x)), r"'@b') 

The resulting state is thus: 

b(h,C,H" + {t" : (t",null),r' : (null, c)}, (t", ({x : r'}, retum(x)), r "@b') , 0) | 
b'(h",C',H"' + {r"' : (t',null)},OT,{r"' ; {(t', (B + {time : r'"}, command = ...;), null)}}) | 

A,R" =^ 

To return the result back to the calling agent we have to apply rule [RemoteReturn] . Before 
we need to associate the agents, we skip over this part. The value to be placed in the heap of the 
calling agent b', the target of return, must be a clone of the value in the heap of b. The operation 
is performed by the copy function. 

evalin" + {t" : (t", null), r' : (null, c)}, t", {x : r'}, x) = c 

copy,,, (C, H + {t" : (t", null), r' : (null, c)}, c) = (0, 0, c) 

Thus, we obtain: 

(b(h,C,H" + {t" : (t",null),r' : (null, c)}. Or, 0) | 
b'(h", C', H'" + {r'" : (null, c)} , notifyjr'") , {r" : {(t', (B + {time : r'"}, command = ...;), null)}})) | 

A,R" 

We may now apply rule [Notify] to wake the calling thread. Remember that in order to apply 
the rule on agent b' we need to disassociate and commute the agents. 

b'(h",C',H"' + {r'" : (null, c)}, (t', (B + {time : r'"}, command = ),null),0) | 
b(h,C,H" + {t" : (t",null),r' : (null, c)}. Or, 0) | A, R" 

Thus, the thread that performed the method invocation resumes its execution, with a binding 
for the value (c), through reference r'". We conclude here the partial execution of our example. 
The server agent enters a state of idleness waiting for new requests, while the agent will execute 
the setTimeApplication binary program to set the local clock. 

8 Conclusions 

In this report we have presented the syntax and semantics for the core of a language for program- 
ming mobile agents, named Mob. A new report, focusing on the encoding of the semantics of this 
language into a process calculus is currently being prepared. 

The Mob core-language compiler and run-time system are implemented. The first is an im- 
plementation of the encoding to be presented in the next report, and the second an extension to 
the distributed TyCO run-time to allow the execution of Mob computations. 

The run-time is currently being extended with primitives for interaction with external ser- 
vices. This will allow Mob to act as a coordination language for mobile agents that interact 
with web services for: recognition/execution of programs in several high-level languages, building 
itineraries through external search engines, database transactions, and network communication 
through known protocols, such as SMTP, FTP, or HTTP. 

Future plans also include an integrated tool for programming, debugging and monitoring 
agents. 
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